<html>
<head><meta charset="utf-8"><title>unsafe and #[target_feature] · t-lang/wg-unsafe-code-guidelines · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/index.html">t-lang/wg-unsafe-code-guidelines</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html">unsafe and #[target_feature]</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="240110258"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240110258" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240110258">(May 24 2021 at 20:52)</a>:</h4>
<p>What is <code>unsafe</code> even for? I know this may seem like a totally deranged question, but please bear with me.<br>
Obviously it confers the power to</p>
<blockquote>
<p>Dereference a raw pointer<br>
    Call an unsafe function or method<br>
    Access or modify a mutable static variable<br>
    Implement an unsafe trait<br>
    Access fields of unions</p>
</blockquote>
<p>But what, notionally, is the purpose... and limits... of <code>unsafe</code>? Is it just memory safety? Does it cover all possible UB? What are the limits of Rust's considerations? I raise this question because <code>#[target_feature]</code> seems like it might be implying something subtly different from memory safety. Obviously Rust can technically actually violate memory safety, a la <a href="https://crates.io/crates/totally-safe-transmute">https://crates.io/crates/totally-safe-transmute</a>, but we tend to punt on that because it's an OS provided API. So to what extent is Rust actually <em>allowed</em> to consider the machine it is running on? Whence cometh the consideration of the risk of unsoundness for SIMD instructions but not for <code>totally-safe-transmute</code>?</p>



<a name="240110517"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240110517" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Steven Fackler <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240110517">(May 24 2021 at 20:54)</a>:</h4>
<p><code>unsafe</code> covers all forms of UB. <code>target_feature</code> is an interesting case though! If trying to run an instruction on a CPU that doesn't supported just triggered a SIGILL, then <code>unsafe</code> wouldn't be required. However, I think it turned out that, at least in some obscure contexts, new CPU instructions sometimes recycled the opcodes of old CPU instructions, and so running code targetting a certain target feature on a very old CPU could actually run semantically different operations than were intended.</p>



<a name="240110572"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240110572" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Steven Fackler <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240110572">(May 24 2021 at 20:55)</a>:</h4>
<p>I can't remember exactly what, but maybe some very early 16 bit real mode x86 opcodes overlap with some of the new AVX extensions?</p>



<a name="240110690"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240110690" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Steven Fackler <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240110690">(May 24 2021 at 20:56)</a>:</h4>
<p>Oh, there's an example of that up above in the other thread!</p>



<a name="240111414"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240111414" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240111414">(May 24 2021 at 21:01)</a>:</h4>
<p>Then what, philosophically, is undefined behavior, anyways? :^)<br>
I know, I know, "prescribed to be unpredictable", but when <strong>must</strong> Rust insist that the result is unpredictable? Because if we emit aarch64 code, and then you run it on an x86 processor, that's not exactly going to produce more deterministic behavior, nonetheless, at the risk of sounding absurd, we do not actually weigh that, afaik, in our design (it's not <code>unsafe fn main()</code> after all) but we do consider it for target features for a given individual processor, even though it's already definitionally UB to execute that code.</p>
<p>At what point, exactly, did Rust acquire that burden?</p>



<a name="240112318"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240112318" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240112318">(May 24 2021 at 21:09)</a>:</h4>
<p>UB as is usually defined for programming language purposes is not a concept that exists after the compiler is done emitting the machine code. Hardware has its own kinds of UB like for instance indeterminate results when logic voltage is too low, but that's not something a programming language needs to concern itself with… right?</p>
<p>It still isn't clear to me at least as to whether LLVM is allowed to do whatever it wishes during codegen when the features are not available during codegen. At the very least I remember <code>rdrand</code> causing an assertion in LLVM when the <code>rdrnd</code> feature is not enabled.</p>



<a name="240112443"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240112443" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240112443">(May 24 2021 at 21:10)</a>:</h4>
<p>By calling <code>#[target_feature]</code> unsafe we leave ourselves some wiggle-room to decide either way in the future.</p>



<a name="240117925"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240117925" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240117925">(May 24 2021 at 21:59)</a>:</h4>
<p>I would consider that the executing code compiled with a target feature when that feature isn't available is undefined behaviour in general. On x86, it's a #UD exception, but it could actually cause hardware UB on a different ISA. It's entirely possibly that you could hit the HCF instruction. I could presume that is sufficient to warrant unsafe at the rust level.</p>



<a name="240164525"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240164525" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240164525">(May 25 2021 at 09:54)</a>:</h4>
<p>An example of opcode reuse in x86 is <code>lzcnt</code> which is I think <code>rep bsr</code> on older cpus. I once had to debug a bug of cg_clif caused by using lzcnt on an older cpu.</p>



<a name="240169418"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240169418" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240169418">(May 25 2021 at 10:47)</a>:</h4>
<p>What about running code on emulators/virtual machines/etc that have different ideas as to what instructions do compared to real hardware?</p>



<a name="240182436"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240182436" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Steven Fackler <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240182436">(May 25 2021 at 12:56)</a>:</h4>
<p>If you run in a broken VM (or on broken hardware), then you're just kind of screwed. The best we can do is generate correct output according to the relevant specifications.</p>



<a name="240182680"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240182680" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Steven Fackler <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240182680">(May 25 2021 at 12:57)</a>:</h4>
<p>A couple of years ago, I heard a story of an issue where some cloud VMs incorrectly reported that they implemented AES-NI while the underlying hardware did not. Somehow things "worked" well enough for a while until people noticed that their "encrypted backups" were actually just white noise since the AES instructions were just trapping up to the hypervisor!</p>



<a name="240243265"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240243265" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240243265">(May 25 2021 at 20:09)</a>:</h4>
<p><span class="user-mention silent" data-user-id="123586">nagisa</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D/near/240112318">said</a>:</p>
<blockquote>
<p>UB as is usually defined for programming language purposes is not a concept that exists after the compiler is done emitting the machine code. Hardware has its own kinds of UB like for instance indeterminate results when logic voltage is too low, but that's not something a programming language needs to concern itself with… right?</p>
</blockquote>
<p>Hopefully. ^^;</p>
<blockquote>
<p>It still isn't clear to me at least as to whether LLVM is allowed to do whatever it wishes during codegen when the features are not available during codegen. At the very least I remember <code>rdrand</code> causing an assertion in LLVM when the <code>rdrnd</code> feature is not enabled.</p>
</blockquote>
<p>Yeaaah, that's part of why I'm kind of wondering about this in connection with the wasm SIMD and target-feature 1.1 thing, because the question about possible codegen UB was raised there but not fully addressed (though it's not entirely clear how addressable it is, thus...). And then I realized part of my question was sufficiently general that I should separate it out, basically trying to figure out the "reverse" position: where do Rust's obligations to consider what is arguably "beyond Rust" behavior start and stop?</p>



<a name="240244317"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240244317" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240244317">(May 25 2021 at 20:17)</a>:</h4>
<blockquote>
<p>UB as is usually defined for programming language purposes is not a concept that exists after the compiler is done emitting the machine code.</p>
</blockquote>
<p>I guess the "problem" for me, zeroing back on this statement, is that this is what makes it unclear to me where the <code>target_feature</code> burden starts and stops. As Connor says, you could trigger HCF in the CPU... but actually running the code on a given computer with a given feature-set (or absence thereof) happens in a "beyond Rust" scenario, and, well...</p>
<blockquote>
<p>If you run in a broken VM (or on broken hardware), then you're just kind of screwed.</p>
</blockquote>
<p>I am not sure where to draw the line between "broken ISA" vs. "ISA codegen spec vs. execution spec mismatch".</p>



<a name="240244831"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240244831" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240244831">(May 25 2021 at 20:21)</a>:</h4>
<blockquote>
<p>I am not sure where to draw the line between "broken ISA" vs. "ISA codegen spec vs. execution spec mismatch".</p>
</blockquote>
<p>The only difference between a bug and a feature is intent</p>



<a name="240245019"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240245019" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240245019">(May 25 2021 at 20:22)</a>:</h4>
<p>Correct, and yet. ^^;</p>



<a name="240245076"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240245076" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240245076">(May 25 2021 at 20:23)</a>:</h4>
<p>If you are an OS, you often have to just deal with hardware bugs, at which point it just becomes a peculiar architecture. The main problem is when these peculiar architectures can't be detected through the normal mechanisms (CPUID et al)</p>



<a name="240245386"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240245386" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240245386">(May 25 2021 at 20:25)</a>:</h4>
<p><span class="user-mention silent" data-user-id="281757">Jubilee</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D/near/240244317">said</a>:</p>
<blockquote>
<p>I guess the "problem" for me, zeroing back on this statement, is that this is what makes it unclear to me where the <code>target_feature</code> burden starts and stops.</p>
</blockquote>
<p>My understanding is that today we aren't quite sure if LLVM can do unexpected things when you request it to produce the code for an opration which otherwise requires a certain feature to be enabled. Making wasm32 features not require unsafe seems like we'd be going in the direction of saying "no, LLVM does not do that".</p>



<a name="240245488"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240245488" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240245488">(May 25 2021 at 20:26)</a>:</h4>
<blockquote>
<p>And then I realized part of my question was sufficiently general that I should separate it out, basically trying to figure out the "reverse" position: where do Rust's obligations to consider what is arguably "beyond Rust" behavior start and stop?</p>
</blockquote>
<p>I think we should make every effort to detect and mitigate "beyond Rust" problems when possible. (The <code>really_monotonic_clock</code> hack comes to mind.) We may not be able to do much about some kinds of issues, though.</p>



<a name="240245506"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240245506" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240245506">(May 25 2021 at 20:26)</a>:</h4>
<p>For reference: <a href="#narrow/stream/213817-t-lang/topic/safe.20target_feature.20functions.20for.20wasm/near/238667618">https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/safe.20target_feature.20functions.20for.20wasm/near/238667618</a></p>



<a name="240249021"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240249021" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240249021">(May 25 2021 at 20:57)</a>:</h4>
<p><span class="user-mention silent" data-user-id="281757">Jubilee</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D/near/240244317">said</a>:</p>
<blockquote>
<p>I guess the "problem" for me, zeroing back on this statement, is that this is what makes it unclear to me where the <code>target_feature</code> burden starts and stops. As Connor says, you could trigger HCF in the CPU... but actually running the code on a given computer with a given feature-set (or absence thereof) happens in a "beyond Rust" scenario, and, well...</p>
</blockquote>
<p>Well, combining things like <code>target_feature</code> and <code>is_&lt;arch&gt;_feature_detected!</code>, I'd argue that it is within the purview of rust to consider execution environments as having "particular" features, even if the consideration extends no further than a simple <em>conditionally-supported</em> statement.</p>



<a name="240249258"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240249258" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240249258">(May 25 2021 at 20:59)</a>:</h4>
<p>(As a semi-related note, I would consider that target features are <em>conditionally-supported</em> already, even if there isn't normative text on the subject, and lacking otherwise defined behaviour, the unsupported case falls back to UB)</p>



<a name="240251506"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240251506" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240251506">(May 25 2021 at 21:17)</a>:</h4>
<blockquote>
<p>lacking otherwise defined behaviour, the unsupported case falls back to UB</p>
</blockquote>
<p>I don't think Rust has UB-of-the-gaps like this. If something is unspecified that doesn't mean it's UB, that means the spec is incomplete</p>



<a name="240252001"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240252001" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240252001">(May 25 2021 at 21:22)</a>:</h4>
<p>I mean, what else can a spec gap be? If something doesn't have defined behaviour by the spec, what limits are imposed on the behaviour that can be assigned by the implementation? There is a difference between unspecified and "is not present in the specification".</p>



<a name="240252103"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240252103" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240252103">(May 25 2021 at 21:23)</a>:</h4>
<p>(It's also generally the case, at least in C and C++, that when a <em>conditionally supported</em> feature is unsupported, it's use is either ill-formed or undefined behaviour)</p>



<a name="240252280"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240252280" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240252280">(May 25 2021 at 21:24)</a>:</h4>
<p>Yes, this is a deliberate departure from C/C++ specs where spec omissions are UB</p>



<a name="240252437"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240252437" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240252437">(May 25 2021 at 21:26)</a>:</h4>
<p>If there is a spec gap, that doesn't mean anything other than that the spec is incomplete/buggy/needs to be fixed. It doesn't imply that the behavior is defined, undefined, conditionally-supported or anything else like that</p>



<a name="240252597"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240252597" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240252597">(May 25 2021 at 21:28)</a>:</h4>
<p>UB of the gaps! <span aria-label="joy" class="emoji emoji-1f602" role="img" title="joy">:joy:</span> <br>
<span class="user-mention silent" data-user-id="271719">Mario Carneiro</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D/near/240245488">said</a>:</p>
<blockquote>
<p>I think we should make every effort to detect and mitigate "beyond Rust" problems when possible. (The <code>really_monotonic_clock</code> hack comes to mind.) We may not be able to do much about some kinds of issues, though.</p>
</blockquote>
<p>I think, for Rust at least, the <code>really_monotonic_clock</code> hack happens to be a situation where we are trying to undermine a type violation that is directly "in Rust" (that is, we promised monotonicity). So we can either hack monotonicity in or repeal the promise of monotonicity. The latter is a breakage of the kind that Rust's semver policies arguably might <strong>not</strong> permit without incrementing Rust Major, in spite of being a fix.</p>



<a name="240252874"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240252874" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240252874">(May 25 2021 at 21:31)</a>:</h4>
<p>I think totally-safe-transmute falls in the same category though; it is an OS feature that directly undermines a promise that rust is trying to make. The only difference is that there is very little we can do about it. It's in the same category as trying to prove that a program doesn't have any panics and then someone pulls the plug on the computer</p>



<a name="240253217"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240253217" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240253217">(May 25 2021 at 21:35)</a>:</h4>
<p><span class="user-mention silent" data-user-id="271719">Mario Carneiro</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D/near/240251506">said</a>:</p>
<blockquote>
<blockquote>
<p>lacking otherwise defined behaviour, the unsupported case falls back to UB</p>
</blockquote>
<p>I don't think Rust has UB-of-the-gaps like this. If something is unspecified that doesn't mean it's UB, that means the spec is incomplete</p>
</blockquote>
<p>In either case, it could just as easily be a split statement. The text I would write in that case could be:</p>
<blockquote>
<ul>
<li>If a function with a <code>#[target_feature]</code> attribute is called in a context where a feature indicated is not enabled, the program is ill-formed if the call does not occur within an unsafe context. Such a call is <em>conditionally-supported</em>, and the behaviour is undefined if unsupported. [Note: An implementation may make use of features enabled by the <code>#[target_feature]</code> attribute to generate better optimized code than may be possible in the remainder of the crate]</li>
</ul>
</blockquote>



<a name="240253338"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240253338" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240253338">(May 25 2021 at 21:36)</a>:</h4>
<p>(If UB-by-deliberate omission is permitted, I would simply stop the normative text at "Such a call is <em>conditionally-supported</em>")</p>



<a name="240253373"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240253373" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240253373">(May 25 2021 at 21:36)</a>:</h4>
<p>Yeah in practice the monotonicity hack is there because it is something that can be controlled within the scope of the Rust program. So I guess we could apply a similar reasoning here and say that <code>unsafe</code> only applies to things which can be governed entirely within Rust control flow.</p>



<a name="240253413"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240253413" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240253413">(May 25 2021 at 21:37)</a>:</h4>
<p>Now we just need to provide a definition of Rust control flow which I am sure will be simple and non-controversial. <span aria-label="upside down" class="emoji emoji-1f643" role="img" title="upside down">:upside_down:</span></p>



<a name="240253636"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240253636" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240253636">(May 25 2021 at 21:40)</a>:</h4>
<p>For the cases of buggy processors, I would agree. In general, though ,<code>#[target_feature]</code> is close fairly close to what I described in the Note: a indication that the implementation is allowed to generate more optimized code, using the indicated features. To facilate that optimization, it must therefore be undefined behaviour to enter that code where the feature is unavailable, otherwise such optimizations would arguably violate the <em>as-if</em> rule.</p>



<a name="240253716"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240253716" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240253716">(May 25 2021 at 21:41)</a>:</h4>
<p>The architecture and the ISA is, primarily, a detail of the implementation. It's how the implementation chose to emulate the required observable behaviour of the Abstract Machine, whatever that means for rust.</p>



<a name="240254012"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240254012" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240254012">(May 25 2021 at 21:44)</a>:</h4>
<p>(Also, making it undefined behaviour to enter code that requires unavailable target features would be useful for abi issues accross such bounderies)</p>



<a name="240256304"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240256304" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240256304">(May 25 2021 at 22:06)</a>:</h4>
<p>I agree that it should be undefined behavior to call a function with an unsupported <code>#[target_feature]</code>. That is more or less forced by the hardware, since it's essentially hardware UB already. Whether that entails <code>unsafe</code> depends on the degree to which we can statically ensure that we only ever call functions when the target features are supported.</p>



<a name="240256614"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240256614" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240256614">(May 25 2021 at 22:09)</a>:</h4>
<p>What about the WebAssembly case, where we have what we assume is a static guarantee that entering unsupported features will trap? To what degree do we allow the implementation details of the underlying """hardware""" to leak into Rust when it reduces possible cases of UB?</p>



<a name="240256877"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240256877" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240256877">(May 25 2021 at 22:12)</a>:</h4>
<p>A function that is always safe to call (i.e. never causes UB) does not need to be marked <code>unsafe</code>. We already do this kind of thing with "safe wrappers", but it can also be implemented directly on the intrinsic. The spec already knows what is UB and what isn't so it can include language to this effect.</p>



<a name="240257276"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240257276" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240257276">(May 25 2021 at 22:16)</a>:</h4>
<blockquote>
<p>I agree that it should be undefined behavior to call a function with an unsupported <code>#[target_feature]</code></p>
</blockquote>
<p>Actually this needs to be amended to "conditionally-supported" since making all unsupported features UB would exclude the wasm case. Ideally the spec should enumerate the status of all target features - whether they are known to trap, are known to be UB, or have some other status</p>



<a name="240266095"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240266095" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240266095">(May 26 2021 at 00:16)</a>:</h4>
<p>I'd argue that, even in the wasm case where the runtime result is known, it's still necessary to make it undefined behaviour, in order to release the implementation from that burden. Otherwise, rust would have to define exactly what all happens in that case, which can be difficult, and "trapping" wouldn't be able to consider <code>SIGILL</code>.<br>
Also, I'd argue that the list of target features shouldn't be exhaustive in the spec, and should rather be <em>implementation-defined</em> (possibly with a minimum supported list for some common architectures). In particular, I would personally rather avoid constraining the architectures available to rust implementations, and requiring admission into the specification (which may not be granted for some architectures, but various implementations may be capable of supporting them trivially).</p>



<a name="240274105"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240274105" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240274105">(May 26 2021 at 02:50)</a>:</h4>
<blockquote>
<p>it's still necessary to make it undefined behaviour, in order to release the implementation from that burden</p>
</blockquote>
<p>I just realised that the burden I'm referring to may not be obvious. I'm referring to the burden of either issuing the trap as required (even if it doesn't make use of the target_feature), or maintaining correct state of the AM for the purposes of determining observable behaviour (if it does).</p>



<a name="240275625"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240275625" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240275625">(May 26 2021 at 03:24)</a>:</h4>
<blockquote>
<p>Also, I'd argue that the list of target features shouldn't be exhaustive in the spec, and should rather be implementation-defined (possibly with a minimum supported list for some common architectures). In particular, I would personally rather avoid constraining the architectures available to rust implementations, and requiring admission into the specification (which may not be granted for some architectures, but various implementations may be capable of supporting them trivially).</p>
</blockquote>
<p>I've been thinking about what a formal specification of rust would look like these days, and it's really not clear to me how to model divergent architectures unless the possible behaviors are explicitly enumerated. That may well mean that the spec is limited to Tier-1 targets, but generalizing over all possible behaviors while also not being UB somehow seems like a very difficult balance otherwise.</p>



<a name="240275731"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240275731" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240275731">(May 26 2021 at 03:26)</a>:</h4>
<p><span class="user-mention silent" data-user-id="257758">Connor Horman</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D/near/240274105">said</a>:</p>
<blockquote>
<blockquote>
<p>it's still necessary to make it undefined behaviour, in order to release the implementation from that burden</p>
</blockquote>
<p>I just realised that the burden I'm referring to may not be obvious. I'm referring to the burden of either issuing the trap as required (even if it doesn't make use of the target_feature), or maintaining correct state of the AM for the purposes of determining observable behaviour (if it does).</p>
</blockquote>
<p>We're supposing for the sake of discussion that WASM <em>does</em> issue the trap as required under all circumstances. If that can't be guaranteed then obviously we can't remove the <code>unsafe</code>.</p>



<a name="240276155"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240276155" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Quy Nguyen <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240276155">(May 26 2021 at 03:36)</a>:</h4>
<p>Couldn't a formal specification of Rust lean heavily on implementation-defined behavior? A formal spec for Rust should be able to support at least a large subset of targets, or else it risks just being ignored and rustc being the defacto standard.</p>



<a name="240276853"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240276853" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240276853">(May 26 2021 at 03:53)</a>:</h4>
<p>The thing is, it's not clear to me what it means to "lean heavily on implementation-defined behavior". That sounds like the spec is parameterized on a huge number of functions specifying the semantics of individual instructions to the point that the spec itself offers very little and it may not even be clear that a model exists</p>



<a name="240276935"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240276935" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240276935">(May 26 2021 at 03:54)</a>:</h4>
<p>I would rather just see all supported targets in the spec, since that's what rustc does (possibly with some generic / parameterized behavior for other targets as a template for future expansion)</p>



<a name="240277022"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240277022" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240277022">(May 26 2021 at 03:56)</a>:</h4>
<p>Well trap doesn't have a defined behavior actually.<br>
I mean, it does, but it also doesn't: it generates an exception of some unspecified nature, but deterministically, and returns control flow to the environment beyond wasm.</p>



<a name="240277045"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240277045" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240277045">(May 26 2021 at 03:57)</a>:</h4>
<p>That sounds like "as good as a panic". In particular execution visibly terminates abnormally and instructions following the trap are not executed</p>



<a name="240277108"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240277108" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240277108">(May 26 2021 at 03:58)</a>:</h4>
<p><code>std::process::abort</code> is a safe function</p>



<a name="240281812"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240281812" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240281812">(May 26 2021 at 05:44)</a>:</h4>
<p>but you have to spec no_std / bare metal too</p>



<a name="240303614"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240303614" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240303614">(May 26 2021 at 10:23)</a>:</h4>
<p><span class="user-mention silent" data-user-id="271719">Mario Carneiro</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D/near/240275731">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="257758">Connor Horman</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D/near/240274105">said</a>:</p>
<blockquote>
<blockquote>
<p>it's still necessary to make it undefined behaviour, in order to release the implementation from that burden</p>
</blockquote>
<p>I just realised that the burden I'm referring to may not be obvious. I'm referring to the burden of either issuing the trap as required (even if it doesn't make use of the target_feature), or maintaining correct state of the AM for the purposes of determining observable behaviour (if it does).</p>
</blockquote>
<p>We're supposing for the sake of discussion that WASM <em>does</em> issue the trap as required under all circumstances. If that can't be guaranteed then obviously we can't remove the <code>unsafe</code>.</p>
</blockquote>
<p>Does it guarantee a trap even if the implementation chooses not to exploit the <code>#[target_feature]</code> as permitted? If so, then it could be <em>implementation-defined</em> whether the implementation issues a trap instead. But specifying that trap is either going to be incredibly handwavying (without being exhaustive), or insufficient to handle all cases, when the undefined behaviour case would permit the issuance of a trap (and also permit the implementation making an independant promise of such).</p>



<a name="240303990"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240303990" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240303990">(May 26 2021 at 10:27)</a>:</h4>
<p><span class="user-mention silent" data-user-id="271719">Mario Carneiro</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D/near/240276853">said</a>:</p>
<blockquote>
<p>The thing is, it's not clear to me what it means to "lean heavily on implementation-defined behavior". That sounds like the spec is parameterized on a huge number of functions specifying the semantics of individual instructions to the point that the spec itself offers very little and it may not even be clear that a model exists</p>
</blockquote>
<p>imo the rust spec should be agnostic of the finite list of supported targets. It should neither mandate implementations support any particular platform, nor forbid such (either implicitly or explicitly) beyond generic specification requirements that consequentially limit implementation platforms.</p>



<a name="240308447"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240308447" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240308447">(May 26 2021 at 11:17)</a>:</h4>
<blockquote>
<p>imo the rust spec should be agnostic of the finite list of supported targets.</p>
</blockquote>
<p>How then does one define the behavior of <code>#[cfg(target_arch = "x86_64")]</code>? Presumably implementations are not allowed to disagree on the abstract machine semantics of a program using such cfg directives. But the only way to establish such semantics is to put x86-specific constraints literally in the spec. It can be done in an open ended way, but I don't think a rust implementation that swaps the meaning of <code>target_arch = "x86_64"</code> and <code>target_arch = "arm"</code> should be considered conforming, because a perfectly well defined rust program running under rustc could cause almost arbitrary misbehavior if run on an incompatible architecture.</p>



<a name="240310014"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240310014" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240310014">(May 26 2021 at 11:33)</a>:</h4>
<p><span class="user-mention silent" data-user-id="271719">Mario Carneiro</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D/near/240308447">said</a>:</p>
<blockquote>
<blockquote>
<p>imo the rust spec should be agnostic of the finite list of supported targets.</p>
</blockquote>
<p>How then does one define the behavior of <code>#[cfg(target_arch = "x86_64")]</code>? Presumably implementations are not allowed to disagree on the abstract machine semantics of a program using such cfg directives. But the only way to establish such semantics is to put x86-specific constraints literally in the spec. It can be done in an open ended way, but I don't think a rust implementation that swaps the meaning of <code>target_arch = "x86_64"</code> and <code>target_arch = "arm"</code> should be considered conforming, because a perfectly well defined rust program running under rustc could cause almost arbitrary misbehavior if run on an incompatible architecture.</p>
</blockquote>
<p>The value of each <code>target_*</code> cfg key is implementation defined.</p>



<a name="240310227"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240310227" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240310227">(May 26 2021 at 11:36)</a>:</h4>
<p>And then it's constrained that <code>core::arch::x86_64</code> exists if <code>cfg(target_cpu="x86_64")</code>, which contains various things (and those have particular behaviour within the abstract machine).</p>



<a name="240310552"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240310552" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240310552">(May 26 2021 at 11:39)</a>:</h4>
<p>It can contain particular constraints on existing well-known architectures, but, for example, if I wanted to implement the <code>w65</code> architecture, it is my opinion that rust should not prohibit that implementation choice. Likewise, if I don't want to implement the aarch64 architecture, rust shouldn't require that it's implemented (that would constrain something like gcc-rs, which is a single-target toolchain).</p>



<a name="240311202"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240311202" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240311202">(May 26 2021 at 11:46)</a>:</h4>
<p>I don't think either of those criteria are difficult to achieve, although for the <code>w65</code> example we would have to leave in some room to potentially extend the spec to cover the architecture "properly", at which point an early adopter implementation may become nonconforming</p>



<a name="240311569"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240311569" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240311569">(May 26 2021 at 11:50)</a>:</h4>
<p>Well, at that point, I would presume that the implementor would be able to offer that experience to avoid that issue.</p>



<a name="240428096"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240428096" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240428096">(May 27 2021 at 07:16)</a>:</h4>
<p>Supported targets are necessarily part of the Rust language and library, because the language and library define target-specific behavior. If nothing else, there needs to be information about what sizes and layouts various types have, as well as what modules are defined for that target.</p>



<a name="240428268"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240428268" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240428268">(May 27 2021 at 07:19)</a>:</h4>
<p>If you'd like to implement w65, the same issues apply as if you want to add any other new language feature; either way it needs some amount of design work.</p>



<a name="240447790"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240447790" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240447790">(May 27 2021 at 10:50)</a>:</h4>
<p>The issue comes when the people in charge of the design has no reason to pursue designing a feature. w65 in particular is close to 40 (may even be more) years old, and sees limited use. I have reasons to support it (related to SNES Homebrew development),  but  I doubt many other people do.  Thus I find it extraordinarily unlikely that w65 would be explicitly supported by the Rust Language.<br>
 I would also prefer <em>not</em> having to do the extra work to gate off targets that rust doesn't permit, when the default state for my design is to permit it (my design just parses the target tuple, then passes it to the frontend, and the frontend can obtain information about the target).  Modules are somewhat fair (though they can easily be introduced with a feature gate, as could inline assembly), but I'd argue that size and layout could easily be made <em>implementation-defined</em> rather than exhaustively enumerating the values. Likewise, <code>target_feature</code>s could be <em>implementation-defined</em>.</p>



<a name="240451712"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240451712" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240451712">(May 27 2021 at 11:31)</a>:</h4>
<p>The fact that size is at least u16 is baked in to the standard library at least.</p>



<a name="240452400"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240452400" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240452400">(May 27 2021 at 11:38)</a>:</h4>
<p>Yes, that would be a constraint on the <em>implementation-defined</em> size of <code>usize</code>.</p>



<a name="240496669"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240496669" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240496669">(May 27 2021 at 16:43)</a>:</h4>
<p><span class="user-mention" data-user-id="257758">@Connor Horman</span> So, two things about that:<br>
1) If the standards for tier 3 are such that SNES homebrew development can't meet them, we've done something very wrong. ;)  I very much hope that in general, the standards for tier 3 (unlike the higher tiers) are a sufficiently minimal set that they would be more-or-less what any other implementation would want anyway.<br>
2) If it turns out that there's a second relevant implementation for which (1) is not actually true in practice, I imagine we could expand our processes such that we could collaboratively determine the minimum details needed for uniform handling of the target, such as target triple name, type sizes, and similar. We could even add a concept of "tier 4 targets": "this isn't in the codebase, but there's enough consensus on it to not end up with incompatible implementations in the future".</p>



<a name="240526728"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240526728" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240526728">(May 27 2021 at 20:28)</a>:</h4>
<p>I agree that if Rust can't compile for the SNES then I'm rioting.</p>



<a name="240526757"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240526757" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240526757">(May 27 2021 at 20:28)</a>:</h4>
<p>I mean I don't expect to load up an actual cartridge any time soon.</p>



<a name="240528187"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240528187" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240528187">(May 27 2021 at 20:40)</a>:</h4>
<p>I would love to, but sadly my console's video output isn't reliable anymore.</p>



<a name="240529694"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240529694" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240529694">(May 27 2021 at 20:51)</a>:</h4>
<p><span class="user-mention silent" data-user-id="281757">Jubilee</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D/near/240526728">said</a>:</p>
<blockquote>
<p>I agree that if Rust can't compile for the SNES then I'm rioting.</p>
</blockquote>
<p>Well, I doubt rustc specifically would be able to compile it any time soon, I've abandoned my efforts for implementing a w65 backend for llvm. That being said, my primary issue is with <code>usize</code> (pointers are 24-bit zero-extended to 32-bit, but the size type is 16-bit). But it's a lot more of an issue if Rust itself prohibits the implementation, either explicitly, or by exhaustively listing the required ones, then if there are technical details that have to be solved.</p>



<a name="240530272"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240530272" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240530272">(May 27 2021 at 20:55)</a>:</h4>
<p>would rustc-codegen-gcc solve the "no llvm target" issue?</p>



<a name="240530824"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240530824" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240530824">(May 27 2021 at 20:59)</a>:</h4>
<p>There alas also isn't a gcc target, though I'm working on (re)implementing binutils, so it or gcc rs might have some in not-upstream in the future. I'm also working on an implementation (of not just rust) that will come with w65 support (where the"I'd rather not have to specifically exclude targets" issue arises).</p>



<a name="240533146"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240533146" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240533146">(May 27 2021 at 21:16)</a>:</h4>
<p>I think the Rust specification could say that, for targets that are not addressed specifically by the specification, the behavior is implementation-defined.</p>



<a name="240534071"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240534071" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240534071">(May 27 2021 at 21:25)</a>:</h4>
<p>Probably doesn't even need to say for non-addressed targets. If it's just implementation-defined, it can be constrained down to something close to well defined. Fully constraining known platforms also may burden implementations. For example, if rust says that on x86_64, the pointer width is 64, then an implementation could not then operate on x86_64, but compile to the x32 abi (which has only 32-bit pointers, but generates 64-bit code).</p>



<a name="240536079"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240536079" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240536079">(May 27 2021 at 21:44)</a>:</h4>
<p>The x32 ABI has a different target, for exactly that reason.</p>



<a name="240536160"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240536160" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240536160">(May 27 2021 at 21:44)</a>:</h4>
<p><span class="user-mention silent" data-user-id="257758">Connor Horman</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D/near/240529694">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="281757">Jubilee</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D/near/240526728">said</a>:</p>
<blockquote>
<p>I agree that if Rust can't compile for the SNES then I'm rioting.</p>
</blockquote>
<p>Well, I doubt rustc specifically would be able to compile it any time soon, I've abandoned my efforts for implementing a w65 backend for llvm. That being said, my primary issue is with <code>usize</code> (pointers are 24-bit zero-extended to 32-bit, but the size type is 16-bit). But it's a lot more of an issue if Rust itself prohibits the implementation, either explicitly, or by exhaustively listing the required ones, then if there are technical details that have to be solved.</p>
</blockquote>
<p>I don't think Rust should list <em>required</em> targets, just "if you implement this target this is how it must work".</p>



<a name="240536244"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240536244" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240536244">(May 27 2021 at 21:45)</a>:</h4>
<p>I do think, because of that, there's value in Rust saying "a target must be in this list", but that's only a problem if it's non-trivial to extend that list.</p>



<a name="240536286"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240536286" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240536286">(May 27 2021 at 21:45)</a>:</h4>
<p>That's what I was getting at when I suggested "tier 4" targets: we can evaluate a target without necessarily including it.</p>



<a name="240536353"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240536353" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240536353">(May 27 2021 at 21:46)</a>:</h4>
<p>Yeah, I meant permitted targets not required targets there.</p>



<a name="240536636"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240536636" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240536636">(May 27 2021 at 21:49)</a>:</h4>
<p>My primary concern is if some third-party implementation adds a target without any kind of coordination at all, and sets the properties of that target, and then later rustc is expected to preserve some of those properties for compatibility with the third-party implementation.</p>



<a name="240536724"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240536724" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240536724">(May 27 2021 at 21:49)</a>:</h4>
<p>That's the main reason that I don't think it's unreasonable to say "hey, please coordinate the addition of targets". If we refused to participate in that coordination, then I'd certainly understand people deciding they were going to do it anyway.</p>



<a name="240536825"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240536825" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240536825">(May 27 2021 at 21:50)</a>:</h4>
<p>This isn't a hypothetical; this happens for existing targets in other compilers, where the first compiler to target a platform may set a less-than-ideal ABI and subsequent compilers are stuck with it.</p>



<a name="240536972"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240536972" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240536972">(May 27 2021 at 21:52)</a>:</h4>
<p>I'm <em>happy</em> to spend time reviewing "hey, can we have a tier 4 target for (insert arbitrary platform here)" requests if it means that we actually coordinate and design new targets.</p>



<a name="240537040"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240537040" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240537040">(May 27 2021 at 21:52)</a>:</h4>
<p>The reason I say I wouldn't like a specific list of permitted targets, is the way I'd expect the lccc rust frontend to behave when it's told what target to compile for is to query the properties of the target from xlang (the core architecture of lccc), and just follow it. If then the list of targets were restricted, I'd have to implement a whitelist in the rustc driver of the main lccc program, which is extra work, both for myself as the implementor, and the actual program itself (potentially requiring a string hashtable lookup or a tree search, if the target names are exact, like rustc seems to think they are).</p>



<a name="240537215"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240537215" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240537215">(May 27 2021 at 21:54)</a>:</h4>
<p>Is a simple "member of HashSet" check <em>that</em> bad?</p>



<a name="240537239"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240537239" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240537239">(May 27 2021 at 21:54)</a>:</h4>
<p>(Also, you wouldn't have to if every xlang target were covered.)</p>



<a name="240537358"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240537358" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240537358">(May 27 2021 at 21:55)</a>:</h4>
<p>Another option would be for xlang's target data to include Rust target definition information (e.g. "what size is the xyz type"), and then you could do that lookup (which you may need to do anyway) and treat the absence of that information as "this target isn't supported".</p>



<a name="240537476"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240537476" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240537476">(May 27 2021 at 21:56)</a>:</h4>
<p>I just don't want to end up in a world where rustc faces a choice of either "break people using a third-party compiler" or "precisely match the target design from a third-party compiler".</p>



<a name="240537519"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240537519" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240537519">(May 27 2021 at 21:57)</a>:</h4>
<p>I don't think that's good for either third-party compilers or the Rust compiler.</p>



<a name="240538534"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240538534" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240538534">(May 27 2021 at 22:07)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D/near/240537239">said</a>:</p>
<blockquote>
<p>(Also, you wouldn't have to if every xlang target were covered.)</p>
</blockquote>
<p>That issue then becomes I need approval from the rust teams to add a target to the C or the C++ frontend (or to any third party xlang frontend, which, given that I've designed the api to be modular, would make it a non-starter). It's possible I could do the latter (I haven't entirely worked out the design), however, considering I'd already be storing the pointer size, and the lock-free atomic sizes, I can't think of much I would store that wouldn't be just deliberately duplicating information (aside from just storing an explicit <code>bool is_rust_target;</code>, which may not be a bad design)</p>



<a name="240539377"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240539377" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240539377">(May 27 2021 at 22:18)</a>:</h4>
<p><span class="user-mention" data-user-id="257758">@Connor Horman</span> </p>
<blockquote>
<p>That issue then becomes I need approval from the rust teams to add a target to the C or the C++ frontend</p>
</blockquote>
<p>Fair point, and that's <em>not</em> something you should have to do; I didn't want to suggest otherwise. I more meant that since you care about Rust , "every xlang target is a Rust target" may actually be close to the case in practice. :)</p>



<a name="240539431"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240539431" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240539431">(May 27 2021 at 22:19)</a>:</h4>
<p><span class="user-mention silent" data-user-id="257758">Connor Horman</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D/near/240538534">said</a>:</p>
<blockquote>
<p>aside from just storing an explicit <code>bool is_rust_target;</code>, which may not be a bad design</p>
</blockquote>
<p>Yeah, that does seem reasonable and better than a separate list, since you do that target lookup anyway.</p>



<a name="240541648"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240541648" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240541648">(May 27 2021 at 22:48)</a>:</h4>
<p>(Of course, all of this depends on whether or not rust itself considers equivalent but different targets distinct. If so, then I'd have to implement a separate list, since the lookup is against the canonical form, not against the target name)</p>



<a name="240542082"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240542082" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240542082">(May 27 2021 at 22:55)</a>:</h4>
<p>What do you mean by "equivalent but different targets"?</p>



<a name="240542824"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240542824" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240542824">(May 27 2021 at 23:04)</a>:</h4>
<p>Targets that are different in name, but canonicalize to the same thing (xlang performs target canonicalization). For example (though rustc does not accept either, which I consider wrong, as config.guess, at least on my machine, produces the latter) x86_64-linux-gnu canonicalizes to x86_64-pc-linux-gnu. Also, both of these targets are semantically equivalent (though distinct) with x86_64-unknown-linux-gnu (which rustc <em>does</em> accept).</p>



<a name="240544635"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240544635" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240544635">(May 27 2021 at 23:29)</a>:</h4>
<p>I can't imagine any circumstance in which rustc accepted x86_64-pc-linux-gnu and treated it as <em>different</em> than x86_64-unknown-linux-gnu.</p>



<a name="240544667"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240544667" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240544667">(May 27 2021 at 23:29)</a>:</h4>
<p>Either rustc won't accept it at all, or will treat it as identical. Likewise <code>x86_64-linux-gnu</code>.</p>



<a name="240544814"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240544814" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240544814">(May 27 2021 at 23:31)</a>:</h4>
<p>Accepting target aliases has come up before, and I don't think it'd be unreasonable to ask for target alias support in Rust.</p>



<a name="240549969"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240549969" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240549969">(May 28 2021 at 00:51)</a>:</h4>
<p><a href="https://github.com/microsoft/xlang">https://github.com/microsoft/xlang</a>, eh?<br>
As far as targets go, I believe addressing logical targets is preferable to matching exact strings.</p>



<a name="240550663"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240550663" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240550663">(May 28 2021 at 01:03)</a>:</h4>
<p><span class="user-mention silent" data-user-id="281757">Jubilee</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D/near/240549969">said</a>:</p>
<blockquote>
<p><a href="https://github.com/microsoft/xlang">https://github.com/microsoft/xlang</a>, eh?<br>
As far as targets go, I believe addressing logical targets is preferable to matching exact strings.</p>
</blockquote>
<p>Not that, no. I wasn't even aware that existed. The xlang I'm referring to is the middle-architecture of lccc (<a href="https://github.com/LightningCreations/lccc">https://github.com/LightningCreations/lccc</a>).</p>



<a name="240552505"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240552505" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240552505">(May 28 2021 at 01:36)</a>:</h4>
<p>Yeah, I just found it funny.</p>



<a name="240698388"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240698388" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240698388">(May 29 2021 at 11:53)</a>:</h4>
<p><span class="user-mention" data-user-id="281757">@Jubilee</span> </p>
<blockquote>
<p>Then what, philosophically, is undefined behavior, anyways? :^)</p>
</blockquote>
<p>My 2 cents: <a href="https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#undefined-behavior">https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#undefined-behavior</a></p>



<a name="240698448"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe%20and%20%23%5Btarget_feature%5D/near/240698448" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/136281-t-lang/wg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D.html#240698448">(May 29 2021 at 11:54)</a>:</h4>
<p><span class="user-mention silent" data-user-id="123586">nagisa</span> <a href="#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/unsafe.20and.20.23.5Btarget_feature.5D/near/240112318">said</a>:</p>
<blockquote>
<p>It still isn't clear to me at least as to whether LLVM is allowed to do whatever it wishes during codegen when the features are not available during codegen. At the very least I remember <code>rdrand</code> causing an assertion in LLVM when the <code>rdrnd</code> feature is not enabled.</p>
</blockquote>
<p>well, that makes <a href="https://github.com/rust-lang/rust/pull/84988">https://github.com/rust-lang/rust/pull/84988</a> even more interesting...</p>
<p>EDIT: ah okay that was already covered. and then discussion derailed a bit...^^</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>